Recent advances in computer performance have enabled graphic systems to provide more realistic graphical images using personal computers and home video game computers. In such graphic systems, some procedure must be implemented to “render” or draw graphic primitives to the screen of the system. A “graphic primitive” is a basic component of a graphic picture, such as a polygon, e.g., a triangle, or a vector. All graphic pictures are formed with combinations of these graphic primitives. Many procedures may be utilized to perform graphic primitive rendering.
Early graphic systems displayed images representing objects having extremely smooth surfaces. That is, textures, bumps, scratches, or other surface features were not modeled. In order to improve the quality of the image, texture mapping was developed to model the complexity of real world surface images. In general, texture mapping is the mapping of an image or a function onto a surface in three dimensions. Texture mapping is a relatively efficient technique for creating the appearance of a complex image without the tedium and the high computational cost of rendering the actual three dimensional detail that might be found on a surface of an object.
Prior Art FIG. 1 illustrates a graphics pipeline with which texture mapping may be performed. As shown, included is a transform engine 100, a set-up module 102, a rasterizer 104, a texture math module 106, a level of detail (LOD) calculator 108, a texture fetch module 110, a texture filter 112 and a texture combination engine 114. It should be noted that the transform engine 100 and set-up module 102 need not necessarily be required in the graphics pipeline of a graphics integrated circuit.
During operation, the transform engine 100 may be used to perform scaling, rotation, and projection of a set of three dimensional vertices from their local or model coordinates to the two dimensional window that will be used to display the rendered object. The setup module 102 utilizes the world space coordinates provided for each triangle to determine the two dimensional coordinates at which those vertices are to appear on the two dimensional window. Prior Art FIG. 2 illustrates the coordinates 200 of the vertices 201 which define a triangle 202. If the vertices 201 of the triangle 202 are known in screen space, the pixel positions vary along scan lines within the triangle 202 in screen space and may be determined.
The setup module 102 and the rasterizer module 104 together use the three dimensional world coordinates to determine the position of each pixel contained inside each of the triangles. Prior Art FIG. 2A illustrates a plurality of pixels 298 identified within the triangle 202 in such a manner. The color values of the pixels in the triangle 202 vary from pixel to pixel in world space. During use, the setup module 102 and the rasterizer module 104 generate interpolated colors, depth and texture coordinates. The setup module 102 and the rasterizer module 104 then feed the pixel texture coordinates to the texture math module 106 to determine the appropriate texture map colors. In particular, texture coordinates are generated that reference a texture map using texture coordinate interpolation which is commonly known to those of ordinary skill in the art. This is done for each of the pixels 298 identified in the triangle 202. Prior Art FIG. 2A illustrates texture coordinates 299 for the pixels 298 identified within the triangle 202.
Next, a LOD calculation is performed by the LOD calculator 108. Generally, a level of detail (LOD) calculation is used to determine whether a displayed image will be a magnified or minified representation of the texture map. For example, in some occasions, one texel, or texture element, will correspond directly to a single pixel that is displayed on a monitor, where the texel is neither magnified nor minified. In other occasions, the texture map is magnified, where multiple pixels will represent a single texel, or minified, where a single pixel represents multiple texels.
After the LOD calculation, the texture coordinates generated by the texture math module 106 are used to fetch the appropriate texture map colors using the texture fetch module 110. These texture map colors are then filtered by the texture filter module 112. The combiner engine 114 combines together the various colors and textures fetched by the texture fetch module 110 and filtered by the texture filter module 112.
A problem exists with the prior art rendering pipeline described above, with respect to the fact that the hardware of the pipeline is optimized to support an essentially linear topology. Prior art type linear pipelines, and other simplistic non-linear pipelines, tightly couple texture fetch operations with the texture calculation operations. For example, in a given rendering pass, one texture calculation (e.g., texture coordinate calculation) is used to fetch one corresponding texture. Even with parallel texture calculation and fetches, the texture calculations are tightly coupled with their corresponding texture fetches (e.g., 4 texture calculations are directly tied to their corresponding 4 texture fetches. This is a limited design that is static in nature. Since a large amount of state data is associated with the texture calculations, such limited static designs do not scale efficiently.
Thus, there exists a need for a pipeline that allows for more dynamic texture fetches and shading calculations, and in particular, the ability for increasing the number of texture fetch operations that can be performed without an expensive, redundant build up in the amount of texture calculation state data that must be maintained. The present invention provides a novel solution to the above needs.